今來先來處理 Projects，
其實就是 repositoray 相關的設定，
選擇左側 [Resources] -> [Projects] -> [Add]

鍵入你的 project name，
然後 Source Control Credential Type 依照需求選擇，
無腦猜九成都會選 Git 吧？
非常非常古早的時候我是有玩過 Subvesion，沒想到這傢伙現在還有支援…

這是我的設定供參

只有兩點需要稍微注意，
其一就是 Source Control Credential 那邊，
要選擇我們前天教學提到的兩把 key 其中一把：machine-to-github

其二是關於 DevOps 的交付邊界與 repository 切割，
可以看到我這邊其實是把 backend api 的 repo 與維運用的 repo 切開，
我這裡 Project 要 clone 的 repo 是後者，
那你會問，
backend 的 repo 什麼時候 clone 呢？
當然是讓維運 repo 裡的 Ansible playbook 去控

這裡多講一個觀察，
我認為維運的 repo 和 RD 的 repo 要分開，但 RD 的 repository 要能夠自洽，
以 web service 開發來說，Dockerfile 要放在 RD 的一個 microservice 裡，
(就算是 mono 的 app 也可以視為 microservice 只有一個 module 的特例)
以硬體廠開發的角度來說，分成 build from source code 和 deliver as binary e.g. .ko、.so 檔案，
前者要提供 Makefile 與 make command，後者要提供 binary 的交付路徑

也就是說 RD 至少要能夠知道自己的 code 在 production 環境是怎麼被 run 的，
至少要能夠自己編出自己的 module，在 staging 環境上熱插拔(hot-plug)自己負責的範圍，
例如說：
某個 backend service 壞掉了，backend RD 不能只編出 .jar，
如果 production 的環境是 docker compose/docker swarm/kubernetes...etc，
docker-based 的 orchestration，
那麼 RD 至少要有能力編寫/修改/手動打包 docker 吧，
不是所有 docker 相關的事情都推給 CI pipeline/build flow/DevOps

如果對上述論點有點共識，
那就多談兩句我很喜歡 Conway's Law，
這個 1967 年由 Melvin E. Conway 提出的理論

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.

用一張圖表示就像

photo credit

用我自己的話說就是

軟體架構就是軟體開發團隊的形狀

聽起來澀澀的但很合理
業界，或至少我待過的團隊與鄰近的團隊，
一直有 DevOps 到底是誰做的討論，
以至於 DevOps 根本就被當偏義複詞(？)來用，
只有 Ops 沒有 Dev

這也不是三言兩語能講完的主題，
每個人也都有自己的故事，
我直接總結我的建議

1. 以 production 環境適當定義交付邊界，RD 應該要負責一個可以 hot-plug 的 module
2. 允許團隊所有人(RD/QA/DevOps)每季提出一個自動化/pipeline 優化的目標作為考績的一部分
3. End-to-End 從開發到部署的 pipeline 由開發團隊的 tech lead 挑一個出來親自負責

有機會再針對細節掰開揉碎講仔細一點，
放個颱風假廢話也多了起來